Data views: Reduce page selector prominence #58195
Conversation
jameskoster
added
[Type] Enhancement
jameskoster
requested review from
mirka,
oandregal,
ciampo,
jasmussen and
ntsekouras
|
Size Change: +2.72 kB (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 565d185. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7641732303
|
|
Much stronger! Can the chevron be much closer to the chevron? |
packages/dataviews/src/style.scss
Outdated
| .dataviews-pagination__page-selector { | ||
| .components-input-control__backdrop { | ||
| border: 0 !important; | ||
| } | ||
|
|
||
| .components-input-control__container { | ||
| background: transparent !important; | ||
| } | ||
| } |
There was a problem hiding this comment.
This is not ideal, but I don't think we have much choice while waiting for #57720.
Alternatively, we could skip using SelectControl and use vanilla <label /> and <select /> HTML elements
| // translators: %s: Total number of pages. | ||
| _x( 'Page <CurrenPageControl /> of %s', 'paging' ), | ||
| 'of %s', |
There was a problem hiding this comment.
I'm not sure about how easy it is for screen readers to parse the information (ie. Current page is X of Y).
The risk with splitting the strings like this is that the "of Y" structure may not hold true for all locales.
cc'ing @andrewhayward in case he can help with this
One of the motivations here is to reduce the prominence of the selector a great deal, because choosing a page is a very secondary or even tertialy action compared to next/prev pages. In principle it could be a button that opens a modal with a selector instead. That said, this is not the only place this lighter control is meant to be used, if I'm not mistaken it may also be intended for filter controls. To that end I'd hope that moving the chevron much much closer to the number will be good differentiation. |
|
It requires another
That's correct, we'd like to use the same appearance in filter configuration popovers for operator control, e.g.: 
|
|
A few things worth noting...
As Marco noted, I'm also a little wary of losing the border. Technically it doesn't fail SC 1.4.11 (Non-text Contrast), as a border is not required, and the text contrast is sufficient to meet SC 1.4.3 (Contrast), but we should be wary of minimising controls too much.
Screen readers would definitely struggle to pick up on this information. Out of context, the control would be presented with only the label and value available, so any "of Visually, it is also not super clear what the control is/does, so from a cognitive accessibility perspective, I would strongly recommend that we move the chevron fully to the end of the text, and include additional context in the trigger control.
This would make clearer both the purpose of the control, and the connection between the value and the context. It would also increase the tappable footprint.
The internationalisation/translation issue that Marco notes would be resolved with this too, making it easier to structure the text in a way that works across languages/locales. At its simplest, we could set each option to show this context, to minimise having to build any custom solutions.
It would add a little verbosity to screen readers, but this should be minimal. If testing proves this to be an issue, setting an Alternatively, a custom component could be used, rendering the full "Page Finally, aside from the above, the border change breaks the focus styling, which means the dropdown looks more like a disabled control than not. .components-input-control__backdrop {
border: 0 !important;
}
|
|
If keeping the border around the control is out of the question, one option that came to mind is to keep only a bottom border (aka underline the interactive control). |
|
If we have to keep the border, let's find another design altogether, so we can manage prominence. One suggestion could be |
|
It's worth noting that the Andrew's suggestion here (relating to the pagination application) seems reasonable to me, if we're prepared to lose the border. I'd prefer to simplify the repetitious "Page x of x" in the It will always be a bit subjective, but my feeling is that the chevron is the most important visual cue for any select-like control. Perhaps it would be adequate if the hover / focus treatment helps outline the footprint? 
|
I know that @andrewhayward experimented with a few alternative solutions, not sure if any of them would fit the requirements. Maybe:
I agree that a chevron is a good cue, although I'm not expert enough to determine whether a person with cognitive/learning disability or vision impairment would be able to detect that at all. I guess that one option could be to prepare two version of the same control, one without border and one with a border. We could start with the one without border, gather feedback, and switch to the one with border if needed? |
If we have to have the border, we will have to find a different interface altogether. |
|
How to proceed seems fuzzy to me at this point, but it's fairly clear that this PR is not the way to go. |
What?
Reduce the visual prominence of the page selector in the pagination row.
Why?
It currently garners too much attention.
How?
Unfortunately, without building this into the component (#57720) I had to overwrite some of the included styles. I don't feel great about shipping this, but at the same time I'd like to update the visuals here. cc @jasmussen @ciampo @mirka for thoughts on that.
Testing Instructions
Before
After